-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Security Solution][Detections] Implement writing rule execution events to event_log #112286
Conversation
50e175d
to
bc4fe53
Compare
bc4fe53
to
534809c
Compare
e4b69ef
to
1149b28
Compare
Pinging @elastic/security-detections-response (Team:Detections and Resp) |
Pinging @elastic/security-solution (Team: SecuritySolution) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Checked out, tested locally, and reviewed code. Clean implementation and easy to follow, thank you for adding the appropriate deprecations as well. 🙂
Testing was verified against the existing rules (w/o the experimental ruleRegistryEnabled
flag), and confirmed event-log documents correctly included the following new fields:
kibana.alert.rule.execution.status
kibana.alert.rule.execution.status_order
kibana.alert.rule.execution.metrics.execution_gap_duration_s
kibana.alert.rule.execution.metrics.indexing_duration_sum_ms
kibana.alert.rule.execution.metrics.search_duration_sum_ms
Did notice a few 0
entries for kibana.alert.rule.execution.metrics.indexing_duration_sum_ms
, but doesn't look to be introduced as part of this PR since you're just writing the existing result.bulkCreateTimes
.
Also added a nit about including ignore_above
in the mapping, and updating the RFC's provider
format, but all else LGTM! Thanks @xcrzx! 👍 🙂 🚀
...urity_solution/server/lib/detection_engine/rule_execution_log/event_log_adapter/constants.ts
Outdated
Show resolved
Hide resolved
3bda9df
to
a9484e4
Compare
a9484e4
to
8c279c6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @xcrzx, this LGTM 👍 I left a few comments.
...olution/server/lib/detection_engine/rule_execution_log/event_log_adapter/event_log_client.ts
Outdated
Show resolved
Hide resolved
...lution/server/lib/detection_engine/rule_execution_log/event_log_adapter/event_log_adapter.ts
Outdated
Show resolved
Hide resolved
...lution/server/lib/detection_engine/rule_execution_log/event_log_adapter/event_log_adapter.ts
Show resolved
Hide resolved
...olution/server/lib/detection_engine/rule_execution_log/event_log_adapter/event_log_client.ts
Outdated
Show resolved
Hide resolved
...olution/server/lib/detection_engine/rule_execution_log/event_log_adapter/event_log_client.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a bunch of questions / comments. Overall looking good! But there are two kinda blockers:
- left a comment showing an existing alerting event doc, with some suggestions for existing fields used by alerting that should probably be added here, if possible
- no function tests :-). We have some you can probably copy the style from - or at least steal some of our utilities to wait for events to arrive which are pretty useful - the
getEventLog()
function used in the linked test module.
...lution/server/lib/detection_engine/rule_execution_log/event_log_adapter/event_log_adapter.ts
Show resolved
Hide resolved
...olution/server/lib/detection_engine/rule_execution_log/event_log_adapter/event_log_client.ts
Show resolved
Hide resolved
8c279c6
to
69baec1
Compare
69baec1
to
abf4c86
Compare
...urity_solution/server/lib/detection_engine/rule_execution_log/event_log_adapter/constants.ts
Show resolved
Hide resolved
50ded62
to
e6ac128
Compare
I've extended the existing event log schema test with the new fields. Not sure if there are more tests needed as I've touched only schema. On the solution side, we decided not to add tests right now as the exec log is under active development and hidden under a feature flag. @pmuellr, could you please take a look at this PR one more time? We still have an active discussion in the RFC regarding field names, but if that's okay with you, I can make a follow-up PR with field name changes once we have agreed upon them. Exec log implementation is hidden under a feature flag, so only developers will use it; therefore, it should be fine to merge the current field names and change them later. Meantime this PR will allow us to start implementing other Exec Log methods and refactor existing API routes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I submitted a few suggestions, but I'm ok with merging this PR right away and addressing the rest of the field-related considerations in a follow-up PR. We need this code in Security to unblock the next tasks.
@xcrzx 💪 🙌
...olution/server/lib/detection_engine/rule_execution_log/event_log_adapter/event_log_client.ts
Outdated
Show resolved
Hide resolved
...olution/server/lib/detection_engine/rule_execution_log/event_log_adapter/event_log_client.ts
Outdated
Show resolved
Hide resolved
...olution/server/lib/detection_engine/rule_execution_log/event_log_adapter/event_log_client.ts
Outdated
Show resolved
Hide resolved
e6ac128
to
d00aedf
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM; ran Kibana, added an index threshold rule and got it firing, took a peek at the event log from Kibana, everything looks good.
Left a few notes ...
event: { | ||
kind: 'metric', | ||
action: RuleExecutionLogAction['execution-metrics'], | ||
sequence: this.sequence++, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since sequence isn't persisted, it will "roll over" to 0 when Kibana is restarted, and if there are multiple Kibana instances, they will be writing the same sequence
values out while they are running, starting at 0.
Note that we do have field kibana.server_uuid
which uniquely identifies each Kibana instance in case there are multiple.
I assume that's ok, but thought I'd point it out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it should be fine. We will use sequence
as the second sorting argument (sort: ['@timestamp', 'sequence']
). I.e., we need sequence
only to sort events logged in a batch with the same @timestamp
value. So we don't need to handle Kibana restarts and distinguish between multiple instances.
@@ -150,6 +150,21 @@ export default function ({ getService }: FtrProviderContext) { | |||
}, | |||
kibana: { | |||
saved_objects: [savedObject], | |||
space_ids: ['space id'], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test is sufficient for the event log portion of the PR - it ensures that we can actually generate and then read back the same data.
But I assumed you'd want to add some tests for some existing SIEM tests, to make sure when a security rule runs, it's generating the new events. Perhaps we can't right now, as that would also make the PR bigger, having to pull in some rule implementations, or a new FT config needs to be created to enable the execlog, or ...
Figured I'd just point this out - we do have some tests like this using some of our FT-only rules (that always fire, or always fail, etc) - let us know if you need some help building tests like that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
++ We'll need to extend SIEM tests, but I wanted to keep that out of the scope of this PR. I think we'll add tests in a separate PR before enabling the eventLog feature flag by default.
d00aedf
to
2bf9fd9
Compare
💚 Build Succeeded
Metrics [docs]Public APIs missing exports
History
To update your PR or re-run it, just comment with: cc @xcrzx |
💚 Backport successful
This backport PR will be merged automatically after passing CI. |
Co-authored-by: Dmitry Shevchenko <[email protected]>
Addresses: #106469
Summary
To enable EventLog-based client:
Checklist